클로드 코드 완벽 가이드 — 8장 모델 선택, 사용량 관리 딥다이브 학습 노트
출처: 클로드 코드 완벽 가이드 (코드팩토리 최지호) | 참고: https://github.com/codefactory-co
8장에서 다루는 내용
- Opus와 Sonnet의 공통점과 차이점 — 두 모델의 설계 철학과 성능 비교
- 모델 선택 기준 — 작업 형태, 작업 시간, 에이전트 수에 따른 최적 모델 고르기
- 사용량 관리 전략 — 플랜별($100/$200) 토큰 절약과 세션 타이밍 전략
- 남은 토큰량 예측 — /model 커맨드와 Default 모드를 활용한 잔량 추정
전체 흐름도
[클로드 코드 모델 선택 & 사용량 관리]
|
v
+===================================+
| Opus vs Sonnet 이해하기 |
| |
| 공통점 4가지: |
| - 하이브리드 추론 모드 |
| - 병렬 도구 사용 |
| - 향상된 지시 따르기/메모리 |
| - 200K 토큰 컨텍스트 창 |
| |
| 차이점(듀얼 플래그십): |
| Opus 4 = 프런티어 전문가 모델 |
| Sonnet 4 = 고성능 실무자 모델 |
+===================================+
|
v
+-----------------------------------+
| 모델 선택 3가지 기준 |
| |
| 기준 1: 작업 형태 |
| 계획 → Opus / 실행 → Sonnet |
| |
| 기준 2: 작업 시간 |
| 세션 시작 시각 조절로 |
| Opus 사용 시간 극대화 |
| |
| 기준 3: 에이전트 수 |
| 동시 에이전트 많을수록 |
| 토큰 빠르게 소진 |
+-----------------------------------+
|
v
+-----------------------------------+
| 사용량 관리 전략 |
| |
| $100: Opus 연속 약 2시간 |
| $200: 에이전트 3개 동시 시 |
| Opus 약 2~3시간 |
| |
| /model → Default 모드 활용 |
| $100: 20% → Sonnet 전환 |
| $200: 50% → Sonnet 전환 |
| → 남은 토큰 4~5배 예측 가능 |
+-----------------------------------+
선수 지식 체크리스트
- [ ] 클로드 코드 기본 설치 및 실행 방법
- [ ] Pro/Max 플랜의 존재와 가격 차이 ($100 / $200)
- [ ] LLM 모델이란 무엇인지 기본 개념
- [ ] 토큰 개념 (입력/출력 단위)
- [ ] 에이전트(Agent) 기본 개념 (AI가 자율적으로 작업하는 것)
핵심 키워드
| 키워드 | 의미 |
|---|---|
| Opus 4 | 앤트로픽의 프런티어(최상위) 모델. 고급 추론, R&D, 복잡한 에이전트 워크플로에 최적화된 전문가 모델 |
| Sonnet 4 | 지능, 속도, 비용의 균형을 맞춘 고성능 실무자 모델. 프로덕션급 주력 모델 |
| 듀얼 플래그십 (Dual-Flagship) | 단일 최고 모델이 아닌 용도별 두 개의 주력 모델을 운영하는 앤트로픽의 전략 |
| 하이브리드 추론 모드 | 즉각 응답(Near-instant)과 확장된 사고(Extended Thinking)를 모두 지원하는 모드 |
| 세션 | 클로드 코드의 사용 시간 단위. 첫 요청부터 5시간 동안 유지됨 |
| Default 모드 | /model에서 선택하는 기본 모드. Opus를 먼저 쓰다가 일정 사용량 후 자동으로 Sonnet으로 전환 |
섹션 1: Opus와 Sonnet의 공통점
한 줄 요약
Opus와 Sonnet은 설계 목적이 다르지만, 하이브리드 추론 / 병렬 도구 사용 / 향상된 지시 따르기 / 200K 컨텍스트의 4가지 핵심 기능을 공유한다.
쉬운 설명 (자동차 비유)
"스포츠카(Opus)와 세단(Sonnet)은 목적이 다르지만, 둘 다 에어백, ABS, 네비게이션, 후방 카메라는 기본 탑재다."
AI 모델도 마찬가지다: - 하이브리드 추론 모드: 빠른 응답과 깊은 사고를 상황에 따라 전환 - 병렬 도구 사용: 웹 검색 + API 호출 등을 동시에 처리 - 향상된 지시 따르기 및 메모리: 복잡한 다단계 지시를 정확히 수행하고, 시간이 지남에 따라 암묵적 지식을 구축 - 200K 토큰 컨텍스트 창: 약 15만 단어 분량을 한 번에 처리
실무 예제
# 하이브리드 추론 모드 활용 사례
# 간단한 질문 → 즉각 응답 (Near-instant)
"이 변수명 카멜케이스로 바꿔줘"
→ 모델이 빠르게 바로 답변
# 복잡한 질문 → 확장된 사고 (Extended Thinking)
"이 마이크로서비스 아키텍처의 병목을 분석하고 개선안을 제시해줘"
→ 단계별 사고 과정을 거친 후 답변
체크포인트
- [ ] 두 모델의 4가지 공통점을 나열할 수 있는가?
- [ ] 200K 토큰이 약 15만 단어에 해당한다는 것을 이해하는가?
- [ ] 하이브리드 추론 모드의 두 가지 작동 방식을 설명할 수 있는가?
섹션 2: Opus와 Sonnet의 차이점 — 듀얼 플래그십 전략
한 줄 요약
앤트로픽은 "좋은 모델 → 최고 모델"의 단일 진화가 아니라, 용도별로 특화된 두 개의 주력 모델(듀얼 플래그십)을 운영하는 전략을 택했다.
쉬운 설명 (요리사 비유)
"미슐랭 셰프(Opus)에게 라면을 끓여달라고 할 필요는 없다. 라면은 숙련된 조리사(Sonnet)가 더 빠르고 효율적으로 만든다. 하지만 프렌치 코스 요리는 미슐랭 셰프에게 맡겨야 한다."
| 구분 | Opus 4 (프런티어 전문가) | Sonnet 4 (고성능 실무자) |
|---|---|---|
| 포지션 | 기술력 정점, 최고 지능 | 지능+속도+비용 균형 |
| 최적 용도 | 고급 추론, R&D, 복잡한 에이전트 | 코딩, 대용량 처리, 비즈니스 앱 |
| 속도 | 상대적으로 느림 | 상대적으로 빠름 |
| 비용 | 높음 (토큰 소모 많음) | 효율적 |
| 채택 사례 | 연구/개발 환경 | 깃허브, Replit, Sourcegraph |
실무 예제: 벤치마크 성능 비교
┌─────────────────────┬──────────────────┬──────────────────┐
│ 벤치마크 │ Opus 4 │ Sonnet 4 │
├─────────────────────┼──────────────────┼──────────────────┤
│ 에이전틱 코딩 │ 72.5% / 79.4% │ 72.7% / 80.2% │
│ 에이전틱 터미널 코딩 │ 43.2% / 50.0% │ 35.5% / 41.3% │
│ 대학원 수준 추론 │ 79.6% / 83.3% │ 75.4% / 83.8% │
│ 능동적 도구 사용 │ Retail 81.4% │ Retail 80.5% │
│ 다국어 질문과 응답 │ 88.8% │ 86.5% │
│ 시각적 추론 │ 76.5% │ 74.4% │
│ 고등학생 수학 경시대회│ 75.5% / 90.0% │ 70.5% / 85.0% │
└─────────────────────┴──────────────────┴──────────────────┘
주목: 에이전틱 코딩에서는 Sonnet이 Opus보다 약간 높다!
→ SWE Bench Mark에서도 Sonnet이 앞서는 결과가 나옴
→ "항상 Opus가 좋다"는 편견을 깨야 함
체크포인트
- [ ] 듀얼 플래그십 전략의 의미를 설명할 수 있는가?
- [ ] Opus가 Sonnet보다 항상 좋은 것은 아닌 사례를 하나 이상 들 수 있는가?
- [ ] Sonnet을 채택한 실제 기업 3곳을 말할 수 있는가?
섹션 3: 모델 선택 기준 1 — 계획은 Opus, 실행은 Sonnet
한 줄 요약
추상적 사고와 어려운 문제 해결에는 Opus, 계획이 세워진 후 빠르게 코드를 작성하는 실행에는 Sonnet이 최적이다.
쉬운 설명 (건축 비유)
"건축 설계는 유명 건축가(Opus)에게 맡기되, 실제 시공은 숙련된 현장팀(Sonnet)에게 맡기면 비용도 아끼고 속도도 빠르다."
Opus vs Sonnet 역할 분담 패턴
❌ 잘못된 방식: 모든 작업에 Opus만 사용
→ 토큰 빠르게 소진, 비용 낭비
✅ 올바른 방식: 계획/실행 분리
[1] Opus로 설계하고 상세 계획 수립
[2] Sonnet으로 전환하여 계획 실행
[3] 버그 해결 안 될 때만 Opus로 복귀
실무 예제
# 시나리오: 인증 시스템 리팩토링
# STEP 1: Opus로 계획 수립 (복잡한 추상적 사고)
"JWT 기반 인증을 OAuth2로 전환하는 계획을 세워줘.
영향받는 파일, 마이그레이션 순서, 롤백 전략까지 포함해줘."
→ Opus가 상세한 실행 계획 출력
# STEP 2: /model → Sonnet으로 전환 (실행)
"위 계획의 Step 1부터 실행해줘."
→ Sonnet이 동일한 품질로 더 빠르게 코드 작성
# STEP 3: 반복 에러 시 Opus 복귀
"이 에러가 3번째 반복되고 있어. 에러 메시지와 지금까지
시도한 내용을 보고 근본 원인을 찾아줘."
→ Opus가 핵심 원인 파악 → 다시 Sonnet에 위임
체크포인트
- [ ] 계획 단계에서 Opus가 유리한 이유를 설명할 수 있는가?
- [ ] 실행 단계에서 Sonnet을 쓰는 것이 합리적인 이유 2가지를 말할 수 있는가?
- [ ] Opus로 복귀해야 하는 시점을 판단할 수 있는가?
섹션 4: 모델 선택 기준 2 — 작업 시간 (세션 전략)
한 줄 요약
Pro와 Max 플랜 모두 한 세션에 5시간이 주어지며, 첫 요청을 보낸 순간부터 카운트가 시작되므로 세션 시작 시각을 전략적으로 조절해야 한다.
쉬운 설명 (뷔페 비유)
"뷔페에서 2시간 이용권을 샀다면, 입장 직후부터 시간이 흐른다. 화장실 가느라 30분을 날리면 그만큼 손해다. 배고플 때 입장해서 집중적으로 먹어야 본전을 뽑는다."
세션 타이밍 전략 (9시~18시 근무 기준)
시간대 활용 전략
────────────────────────────────────────────
08:00 아무 요청이나 보내서 세션 시작!
↓ (출근 전 공백 1시간 활용)
09:00~12:00 [세션 01] Opus 3시간 집중 사용
12:00~13:00 점심시간
13:00 새 세션 시작! (5시간 초기화)
↓
13:00~16:00 [세션 02] Opus 3시간
16:00~18:00 Sonnet으로 전환 or 미팅
핵심: 8시에 세션을 시작하면 13시까지!
13시에 새 세션을 시작하면 18시까지!
→ 하루에 Opus를 6시간 사용 가능
실무 예제
# 시나리오: 아침에 미팅이 많은 개발자
10:00 코딩 외 업무 마무리 후 첫 요청 전송
→ 세션이 15:00까지 유지
13:00~15:00 점심 후 Opus 집중 사용 (2시간)
15:00 세션 종료 → 새 세션 시작
15:00~18:00 Opus로 3시간 추가 사용
결과: 미팅이 많아도 Opus 5시간 확보!
체크포인트
- [ ] 세션의 5시간이 언제부터 카운트되는지 정확히 아는가?
- [ ] 자신의 근무 패턴에 맞는 세션 시작 시각을 계산할 수 있는가?
- [ ] 세션 시작 시각을 조절하는 것이 왜 중요한지 설명할 수 있는가?
섹션 5: 모델 선택 기준 3 — 동시 실행 에이전트 기준
한 줄 요약
에이전트를 여러 개 동시에 실행하면 토큰이 배로 빠르게 소진되므로, 플랜에 따라 에이전트 수를 전략적으로 관리해야 한다.
쉬운 설명 (수도꼭지 비유)
"물탱크(토큰)는 하나인데, 수도꼭지(에이전트)를 3개 동시에 틀면 물이 3배 빨리 빠진다. 꼭지 수를 조절하지 않으면 정작 필요할 때 물이 없다."
플랜별 에이전트 전략
┌─────────────────────────────────────────────────┐
│ $100 플랜 │
│ │
│ 에이전트 1개로 Opus 연속 사용 → 약 2시간 │
│ 대부분의 상황에서 벗어나지 않는 수준 │
│ │
│ 전략: 가장 중요한 순간에 Opus 집중 사용 │
│ (계획 때만 Opus, 실행 때 Sonnet) │
├─────────────────────────────────────────────────┤
│ $200 플랜 │
│ │
│ 에이전트 3개 동시 실행 시 Opus 약 2~3시간 │
│ Enter만 누르는 바이브 코딩이 아니라면 │
│ 토큰 걱정 크게 안 해도 됨 │
│ │
│ 단, 3개 이상 에이전트는 전략적 고민 필요 │
│ PRD/DDL 등 문맥 작업은 한 곳에서 진행 │
└─────────────────────────────────────────────────┘
실무 예제
# 시나리오: $100 플랜에서 에이전트 전략
# ❌ 비효율적: 에이전트 2개로 Opus를 동시에 쓰면
# 1시간 만에 토큰 소진
# ✅ 효율적: 에이전트 1개만 Opus, 나머지는 Sonnet
# 또는 계획 때만 Opus, 실행은 Sonnet으로
체크포인트
- [ ] $100 플랜에서 Opus로 연속 작업 가능한 시간을 아는가?
- [ ] 에이전트 수가 토큰 소비에 미치는 영향을 이해하는가?
- [ ] $200 플랜에서 3개 이상 에이전트 시 고려할 점을 설명할 수 있는가?
섹션 6: 남은 토큰량 예측하는 방법
한 줄 요약
클로드 코드는 남은 토큰량을 직접 알려주지 않지만, /model 커맨드의 Default 모드를 활용하면 Opus→Sonnet 전환 시점을 기준으로 남은 사용량을 간접 예측할 수 있다.
쉬운 설명 (연료 게이지 비유)
"차에 연료 게이지가 없다면? 주유 후 몇 km를 달렸는지로 남은 연료를 추정할 수밖에 없다. Default 모드는 '연료 절반 남았을 때 경고등 켜주는 기능'과 같다."
Default 모드의 전환 시점
┌─────────────────────────────────────────────┐
│ /model → Select Model │
│ │
│ > 1. Default (recommended) │
│ Opus 4 먼저 → 일정량 후 Sonnet 4 전환 │
│ 2. Opus │
│ 항상 Opus 4 사용 │
│ 3. Sonnet │
│ 항상 Sonnet 4 사용 │
└─────────────────────────────────────────────┘
전환 시점:
$100 플랜 → 사용량 20% 넘기면 Sonnet 전환 알림
$200 플랜 → 사용량 50% 넘기면 Sonnet 전환 알림
남은 토큰 계산법
┌─ $200 플랜 예시 ──────────────────────────────┐
│ │
│ Opus만 사용했을 때 토큰의 50%를 쓰면 │
│ Sonnet 전환 알림이 뜸 │
│ │
│ 이 시점에서: │
│ - Opus만 계속 쓰면 → 지금까지의 1배 더 가능 │
│ - Sonnet으로 전환하면 → 약 5배 더 사용 가능 │
│ │
│ (Sonnet이 Opus 대비 토큰 효율이 높기 때문) │
├─ $100 플랜 예시 ──────────────────────────────┤
│ │
│ Opus만 사용했을 때 토큰의 20%를 쓰면 │
│ Sonnet 전환 알림이 뜸 │
│ │
│ - Opus만 계속 쓰면 → 지금까지의 4배 더 가능 │
│ - Sonnet으로 전환하면 → 약 20배 더 사용 가능 │
└───────────────────────────────────────────────┘
실무 예제
# Opus를 계속 쓰고 싶을 때
/model
→ "2. Opus" 선택
→ Default 모드의 자동 전환을 무시하고 강제로 Opus 유지
# 토큰을 절약하고 싶을 때
/model
→ "3. Sonnet" 선택
→ 처음부터 Sonnet만 사용하여 최대한 많이 사용
# Default 모드 추천 사용법
→ 평소에는 Default로 자연스럽게 사용
→ 중요한 작업이 남았으면 전환 알림 뜰 때 Opus 강제 선택
체크포인트
- [ ] /model 커맨드의 3가지 옵션을 설명할 수 있는가?
- [ ] Default 모드에서 Sonnet으로 전환되는 시점을 플랜별로 아는가?
- [ ] 전환 알림 후 남은 토큰을 Opus/Sonnet 각각으로 얼마나 쓸 수 있는지 계산할 수 있는가?
연습문제
문제 1: 모델 선택 시나리오 (기초)
다음 상황에서 Opus와 Sonnet 중 어떤 모델을 선택해야 하는가?
| 상황 | 선택 |
|---|---|
| (a) 새 프로젝트의 아키텍처 설계 | ? |
| (b) 기존 함수의 변수명 리팩토링 | ? |
| (c) 3번 반복되는 원인불명 버그 해결 | ? |
| (d) 계획이 확정된 후 CRUD API 구현 | ? |
정답 보기
| 상황 | 선택 | 이유 | |------|------|------| | (a) | **Opus** | 추상적 사고와 복잡한 설계 작업 | | (b) | **Sonnet** | 단순 반복 작업, 성능 차이 미미 | | (c) | **Opus** | 어려운 문제 해결, 핵심 원인 분석 | | (d) | **Sonnet** | 계획이 있으면 실행 품질 차이 없음, 속도 우위 |문제 2: 세션 타이밍 계산 (중급)
$100 플랜 사용자가 09:00~18:00 근무한다. 12:00~13:00은 점심시간이다. Opus 사용 시간을 최대화하려면 어떻게 세션을 관리해야 하는가?
정답 보기
**최적 전략:** 1. 08:00에 아무 요청을 보내서 세션 1 시작 → 13:00까지 유효 2. 09:00~12:00: Opus 3시간 집중 사용 3. 12:00~13:00: 점심 (세션 1은 여전히 유효) 4. 13:00에 새 요청으로 세션 2 시작 → 18:00까지 유효 5. 13:00~16:00: Opus 3시간 사용 6. 16:00~18:00: Sonnet으로 전환 또는 미팅 **결과:** Opus를 하루 최대 6시간 사용 가능 (2개 세션 활용)문제 3: 토큰 잔량 판단 (고급)
$200 플랜 사용자가 Opus로 작업 중
/model커맨드를 실행했더니 Default 모드에서 "Sonnet으로 전환한다"는 알림이 떴다. (a) 현재 토큰을 몇 % 사용했는가? (b) 지금부터 Opus만 쓰면 얼마나 더 쓸 수 있는가? (c) Sonnet으로 전환하면 약 몇 배를 더 쓸 수 있는가?
정답 보기
**(a)** 50% 사용 ($200 플랜은 50%에서 전환 알림) **(b)** 지금까지 사용한 양의 1배(같은 양)만큼 더 사용 가능 — 즉 현재까지 쓴 시간과 동일한 시간 **(c)** 약 5배 더 사용 가능 — Sonnet이 Opus 대비 토큰 효율이 높기 때문에, 남은 50%의 토큰으로 Opus 사용 시의 약 5배에 해당하는 대화를 할 수 있다부록 A: 용어 사전
| 용어 | 정의 |
|---|---|
| Opus 4 | Claude 모델 중 최고 성능의 프런티어 모델. 고급 추론, 복잡한 에이전트 워크플로 특화 |
| Sonnet 4 | 성능-속도-비용 균형의 프로덕션급 주력 모델 |
| 듀얼 플래그십 | 하나의 "최고" 모델 대신 용도별 두 주력 모델을 운영하는 전략 |
| 세션 | 첫 요청부터 5시간 동안 지속되는 사용 시간 단위 |
| Default 모드 | /model의 기본 설정. Opus 먼저 사용 후 일정량에서 Sonnet 자동 전환 |
| 하이브리드 추론 모드 | Near-instant 응답과 Extended Thinking을 상황별로 전환하는 기능 |
| 병렬 도구 사용 | 여러 외부 도구(웹 검색, API 등)를 동시에 호출하는 기능 |
| 200K 컨텍스트 창 | 200,000 토큰(약 15만 단어)을 한 번에 처리할 수 있는 입력 창 크기 |
| 에이전트 | AI가 자율적으로 코드를 읽고, 수정하고, 실행하는 독립 인스턴스 |
| /model 커맨드 | 클로드 코드에서 사용할 모델을 전환하는 명령어 |
부록 B: 비교표
Opus 4 vs Sonnet 4 핵심 비교
| 항목 | Opus 4 | Sonnet 4 |
|---|---|---|
| 포지션 | 프런티어 전문가 | 고성능 실무자 |
| 최적 작업 | 고급 추론, 아키텍처 설계, 난해한 버그 | 코딩, 대용량 처리, 비즈니스 앱 |
| 속도 | 상대적으로 느림 | 빠름 |
| 토큰 효율 | 낮음 (많이 소모) | 높음 (효율적) |
| 에이전틱 코딩 | 72.5% / 79.4% | 72.7% / 80.2% |
| 대학원 수준 추론 | 79.6% / 83.3% | 75.4% / 83.8% |
| 수학 경시대회 | 75.5% / 90.0% | 70.5% / 85.0% |
플랜별 사용량 비교
| 항목 | $100 플랜 (Pro) | $200 플랜 (Max) |
|---|---|---|
| 세션 시간 | 5시간 | 5시간 |
| Opus 연속 사용 | 약 2시간 | 에이전트 3개 시 약 2~3시간 |
| Sonnet 전환 시점 | 사용량 20% | 사용량 50% |
| 전환 후 Opus 추가 | 지금까지의 4배 | 지금까지의 1배 |
| 전환 후 Sonnet | 약 20배 | 약 5배 |
| Opus 사용 가능 여부 | O | O |
작업 유형별 모델 선택 가이드
| 작업 유형 | 추천 모델 | 이유 |
|---|---|---|
| 아키텍처 설계 / 기술 계획 | Opus | 추상적 사고, 전체 구조 파악 |
| 복잡한 알고리즘 설계 | Opus | 깊은 추론 필요 |
| 반복되는 난해한 버그 해결 | Opus | 핵심 원인 빠르게 파악 |
| 계획 확정 후 코드 작성 | Sonnet | 속도 빠르고 품질 동일 |
| 단순 코드 수정 / 리팩토링 | Sonnet | 비용 효율적, 속도 우위 |
| 테스트 코드 작성 | Sonnet | 대량 처리에 유리 |
| 문서화 작업 | Sonnet | 속도와 비용 효율 |
부록 C: 참고 자료
| 자료 | 링크 / 설명 |
|---|---|
| 클로드 코드 완벽 가이드 (코드팩토리 최지호) | 본 학습 노트의 원본 서적 |
| 코드팩토리 GitHub | https://github.com/codefactory-co |
| Anthropic 공식 모델 페이지 | https://www.anthropic.com/claude |
| Claude Opus 4 소개 | https://www.anthropic.com/research/claude-opus-4 |
| Claude Sonnet 4 소개 | https://www.anthropic.com/research/claude-sonnet-4 |
| SWE-bench 벤치마크 결과 | https://www.swebench.com — 실제 코딩 벤치마크에서 모델별 성능 비교 |
| Claude Code 공식 문서 | https://docs.anthropic.com/en/docs/claude-code — /model 커맨드 등 상세 사용법 |
클릭하거나 Space를 눌러 뒤집기